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In the Specification 

Please replace the Section entitled "Description of the Preferred Embodiment" 
appearing at Page 6, line 1 through Page 13, line 10, as follows: 



As will be appreciated by those skilled in the art, the detailed implementation of the 
preferred embodiment can be made in numerous ways. Preferably, an object oriented 
environment is used, as it easily represents the various objects and methods described below. 
However, the described system and method can be used with systems of various types. 

The following discussion can be better understood with reference to an example. The 
invention is not limited to a system implementing the described example, but it is used for 
explanatory purposes only. 

In a business that assists users with questions regarding products they have purchased, 
some technique is needed to track the status of numerous inquiries. One approach is to 
provide a "trouble ticket," a document that is passed around containing the history of 
resolving the help request, and other information relevant to the request. This can be 
conceptualized as a physical document, a piece of paper, but is implemented as objects in a 
computer system domain. 

The trouble ticket, referred to herein generically as a "work item," is preferably an 
object in an object oriented computer system. A new work item is created when a help 
request is first made, and exists until the request is completely resolved. The work item can 
change state, be passed to various personnel at various locations for handling, and can be 
modified at various stages. IN In addition, actions can be performed at various stages along 
the way that are not related to modifying the work item itself. 

As an example, a user can contact a help line via a web page accessed over the 
int e rn e t Internet . The user selects a category of problem being encountered, such as a 
hardware problem with a certain brand of laser printer. A description of the problem can be 
entered by a simple text description, or as a series er of responses to questions posed. When 
the user has entered the required information, including identification of the user, a work item 
is generated that must be routed to technical support and responded to. 
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The work item can be placed into a queue for technical support for that particular 
hardware. Eventually a technician takes the work item from the queue, and determines 
whether the problem can be answered based on the information given. If not, additional 
handling may be required, or the technician may need to call or otherwise contact the 
customer for further information. The work item may need to be routed between several 
different people, even several different companies, before it is resolved. Once the problem 
has been solved, which can include on-site repair or replacement, the work item is completed 
and archived. 

The preferred system handles the work item and its routing in a manner that is generic 
and can be used for numerous different business processes. Implemented as a software 
system running on a computer system, Figure 1 illustrates a preferred domain for the system. 
Domain 10 allows access through interface 12, which is the published set of methods by 
which the domain can be accessed. Contained within the domain are a number of composite 
actions 16, described below, and work items 16. Numerous other support and other modules 
and objects are included in domain 10 as known in the art, but the composite actions 14 and 
work items 16 are of primary conceptual interest. All access to the work items 16 is through 
the defined interface 12. 

Figure 2 describes the parts of a work item 16. Each work item 16 has a Category, 
which is used to determine, in part, how the work item 16 is handled. Each work item 16 has 
a State, which indicates where the work item 16 is in the business process flow. Typical 
states could include new, pending, awaiting follow up, completed, and so forth. A State 
indicates whether the work item 16 is open or closed. An open item has been locked by a 
handler process, and work is being done on it. A closed item is waiting in a queue for work 
to be performed. 

Each work item 16 has a Location. All work items must be located in a queue, and 
the location identifies the queue the work item 16 is in. The Creator and Responsible fields 
indicate who created the work item 16, and who is responsible for dealing with it. The 
Responsible field can change during the course of handling the work item. The Due field, 
which may not be used in some cases, indicates when the problem represented by the work 
item must be resolved. This information can be used to, among other tings things , prioritize 
work items in a queue. 
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The History filed field contains a history of all actions that have been undertaken on 
this work item 16. Each time the item is amended in any way, or moved to a different queue, 
the history field is updated. By reviewing the History entry at any time, the comp e t e 
complete sequence of events relating to this work item 16 can be recreated. The Description 
field includes a definition of the problem represented by the work item, and can include text 
and coded indicators. 

Figure 3 shows a composite action 14. Each composite action 14 contains a rule, 
which is a Boolean expression that gives an answer of True or False. The rule can be 
omitted. By linking a series of composite actions together in sequence, nearly any business 
process can be defined by using composite actions 14. 

Three sets of actions are provided. A first set 18 is executed by default when the 
composite action has no rule, or when the rule is not evaluated because of a setting. A second 
set of actions 20 is executed when the Rule evaluates to True, and a third set of actions 22 is 
evaluated when the rule evaluates to False. These actions are any which can be executed by 
the system. Typical actions include sending the work item to a particular queue, sending e- 
mail or fax messages to the customer or a technician, and similar types of notifications. The 
actions can be more complex, and initiate various actions to be performed by the system. For 
example, an action could include access to a database of expert knowledge about a certain 
problem, followed by display of suggested solutions to a technician. 

In the preferred embodiment, each Rule has three possible outcomes. If desired, other 
outcomes can be accommodated, with multi-way logical branching occurring. Each outcome 
of the rule evaluation can have a separate set of actions to be executed, in the manner 
described above. 

Figure 4 is a flowchart illustrating the preferred system in action. Initially, a work 
item 16 is created 30; a trouble ticket in the help desk example described herein. When a 
work item 16 is created, it is assigned a category. Categories are preferably arranged 
hierarchically, so that a user can better define the problem by selecting a lower category. In 
the previous example of a printer hardware problem, high level categories can include, for 
example, hardware and software problems, with lower levels defining with more precision 
the type of hardware having the problem and the nature of the problem itself. 
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Each category has an associated composite action 14. When a work item 16 is 
initially created, the composite action for the associated category is executed on the work 
item 16. Actions may include, for example, an e-mail notification that the work item 16 has 
been entered, and an estimate of the delay before it will be handled. The work item 16 must 
be initially placed into a queue, so each possible set of actions for the composite action 
associated with a category must have an action that places the work item 16 into a queue 32. 

At some future time, the work item 16 is extracted from the queue. This can be done 
by an application executing automatically, or by a person calling up the work item 16 through 
an application operating on her computer. When a work item 16 is opened, it must be locked 
so that another application cannot access it. A composite action is executed on the work item 
34, as described above. 

The composite action can be executed by a technician after reviewing the work item 
16 . For example, after a technician opens a work item 16 relating to a hardware problem 
with a printer, the technician will take an initial step toward resolving the problem. In some 
cases, it may only be necessary to send a prepared reply to the customer explaining how to 
deal with a known, common problem. In others, I it may be necessary to initiate a more 
complicated series of actions to resolve the problem. For example, it may be that the 
symptoms, although appearing to be hardware related, are actually caused by software. The 
technician may then need to transfer the work item 16 to a different queue for processing, and 
send a notification to the customer that this has happened. 

The technician accomplishes activities such as this by selecting an appropriate action 
from a menu or other presentation on her computer display. The selected action then calls the 
corresponding composite action, which in turn executes the actions according to the result of 
its rule. As mentioned previously, these actions can include modifying the work item 16 , 
moving it to a different queue, sending notifications, and so forth. Whenever a composite 
action is executed, the work item history is updated to reflect all changes. 

If the result of the composite action is to change the work item status to complete 36, 
the work item 16 is closed 38 and archived. If processing of the work item 16 is not yet 
complete it is placed in a queue for future processing. 

The result of a composite action may be to leave the work item 16 in the same queue 
for future handling, or to move it to a different queue. In either case, processing of e the 
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work item 16 is similar. Also, an action in a composite action may be to execute another 
composite action. This would result in a sequence of two or more composite actions being 
executed on the work item 16 with no additional input from a technician or the customer. By 
defining the composite actions, a complex workflow can be performed on the work item 16 in 
step 34. Generally, eventually the work item 16 is placed in a queue to await an action or 
decision to be performed by a person, but this is not a requirement. 



FIGURE 5 illustrates a conceptual data flow that can occur in the system described 
above. A work item 16 is initially created by an appropriate process 40 as described above. 
Transport of work items 16 within the common workflow domain is represented by line 42. 
The work item J_6 is placed into one of queues 44, 46, 48. Eventually, it will be picked up by 
the associated handler 50, 52, 54, respectively, and operated upon. Operations by a handler 
50-54 include the execution of one or more composite actions. At the end of such execution, 
the work item 16 is placed into another queue for further processing. As described above, in 
many cases the processing to be performed by a handler executes as the result of a selection 
made by a person after deciding how to deal with the work item 16. 

Queue 56 is used for holding work items 16 that are completed, and process 58 
finishes the task of completing and archiving completed work items 1_6. When the work item 
16 has been completely responded to, as defined by the business processes defined by the 
composite actions, the work item 16 is placed in queue 56 for final disposal. 

The described system and method allow for certain types of businesses processes to 
be efficiently handled in comparison with prior art systems. A trouble ticket ien in 
connection with a help desk has been described as an example, but numerous other situations 
are suitable for the system and method of the invention. For example, nearly any customer 
relationship that requires several different people to wek work on could use the described 
processes. Whenever any piece of work must be handled by different entities at different 
times, the described system and method can usually be defined to handle the process. 

While the invention has been particularly shown and described with reference to a 
preferred embodiment, it will be understood by those skilled in the art that various changes in 
form and detail may be made therein without departing from the spirit and scope of the 
invention. 
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